Service environments are characterized by having two parties: an entity or client that desires the performance of a service; and the service provider who provides the service. In most general terms, a client desirous of a service can be a human, computer program or application, or a device. Likewise, a service provider can be a human, a computer program or application, or a device. A service can be provided at various capacities, levels, or qualities such as speed, reliability, volume, response time etc. In the context of an electronic environment, a service can be viewed as work performed or offered by an application or device as the service provider. It is typically defined in terms of a service state and a set of operations that can be invoked on the service provider. For example, a printer may provide a “printing” service, its state comprising whether the printer is online or offline and its operations being “print file” and “get queue length”. In service environments, services are typically shared among clients and are typically available from multiple service providers. In addition, service providers frequently provide not equal, but equivalent or overlapping services or a range of services. When a client is desirous of the performance of a service, the problem arises that a particular service provider may not be able to provide the exact service as desired. This can be for such reasons as the service is currently allocated to another client, or the exact service is not available from that particular service provider. However, frequently the service provider has alternative services that may meet the needs of the client, although they may not have the exact features that the client requested. Consequently, the client is turned away from that particular service provider and in situations where there is only one service provider available, the needs of the client remain unsatisfied. In addition, frequently similar services are provided by multiple service providers, although no appropriate method exists for efficiently choosing among overlapping services of multiple service providers.
Consequently, there is a need for a mechanism that would allow for a client to negotiate and choose an appropriate service from a service provider offering multiple levels of service. There is also a need for a mechanism to choose efficiently from a number of service providers in a service environment.
Smith, R. G. and Davis R. have disclosed a system called “Contract Net” in a document entitled “Frameworks for Cooperation in Distributed Problem Solving”, IEEE Trans. On Systems, Man and Cybernetics, 1981, pp. 61-70. In the Contract Net system, contracts are established as an explicit agreement between a manager process guaranteeing a task and a contractor process willing to execute the task. A negotiation protocol is used to establish the contract where the manager process advertises the task to be performed to all potential contractors. The contractors, in turn, submit bids. A contract is established between the manager and the lowest bidder. However, the Contract Net system does not explicitly make use of quotes at multiple levels of service. If the task cannot be exactly performed as advertised, the contractor does not submit a bid, even though resources may be available that could meet the desired needs.
Anna-Lena Neches has disclosed a system called FAST (http://info.broker.isi.edu:80/fast) as a procurement service using Electronic Data Interchange (EDI). FAST is a electronic purchasing agent with access to a broad spectrum of distributors and manufacturers. Customers send quote requests and orders to FAST via electronic mail (email). When an electronic quote request is received, FAST obtains quotes from its vendors and returns them to the customer via email. As presently constructed, FAST does not support a negotiation of various levels of service between buyer and seller, such as would be necessary for large volume purchasing contracts. The FAST system is restricted to the application domain of electronic markets.
Other Quality of Service (QOS) negotiation mechanisms have been used for the negotiation for service quality in broadband systems as discussed in “Distributed Multimedia and QOS: A Survey”, Andreas Vogel, Brigette Kerherue, Gregor von Bochmann and Jan Gecsei, IEEE Multimedia, Summer 1995, pp. 10-19. Some of these are based on brokerage mechanisms, however, they (1) do not provide sophisticated quotation mechanisms, and (2) are restricted in their application to the domain of distributed multimedia systems, that is, the QOS parameters are restricted to the quality of data transmission and data representation.
In another prior art system, the Trading Service of the Common Object Request Broker Architecture (CORBA) (reference: OMG, CORBA Services: Object Management Architecture Guide, 1997) provides means for advertising services to a repository and to query the repository by service properties. While service queries to the Trading Service of CORBA can impose constraints on the properties of the disclosed service, the Trading Service neither supports the notion of service level, nor does it associate a cost with providing a service. Furthermore, negotiation is not used to arrive at the service offer, rather it is up to the client to reissue a modified service request (for example, by removing required service properties or relaxing their values) if none of the service providers can meet the constraints.